\section{Definition \& History}
Behavior Driven Design (BDD) was invented and firstly described in 2003 by Dan North. He is known for more than twenty years of work with a focus on applying systems thinking and simple technology to solve complex business problems \cite{North2012}. 

BDD helps to improve the cooperation of Quality Management and Business Analysis in agile software projects. Functionalities, goals and results of the software are written down in a special, textual way so they could be tested automatically later. The requirements are written down as \glqq if-then\grqq\ sentences, based on an ubiquitous language known from Domain Driven Design (DDD) \cite{WikipediaBDD2012}. 
\subsection{Problems with Test Driven Development}
BDD arose from solving issues Dan North had while teaching Test Driven Development (TDD). 
When it came to teach TDD, the same questions appeared all the time:
\begin{itemize}
\item Where to start in the process?
\item What to test and what not to test?
\item How much to test in one go?
\item What to call the tests?
\item How to understand why a test fails?
\end{itemize}

The first thing North mentions is to give the test methods names which equal real sentences, like shown in listing \ref{junit-test}.
\begin{lstlisting}[label=junit-test,caption=Example of well chosen method names in JUnit]
public class CustomerLookupTest extends TestCase {
    testFindsCustomerById() {
        ...
    }
    testFailsForDuplicateCustomers() {
        ...
    }
    ...
}
\end{lstlisting}
Now the class can be parsed by agiledox (see also \cite{Stevenson2003}). The output of agiledox looks like this:\\\\
\parbox[b]{\textwidth}{
\texttt{
CustomerLookup
\begin{itemize}
\item finds customer by id
\item fails for duplicate customers
\end{itemize}
}}
Developers discovered it could do at least some of their documentation for them, so they started to write test methods that were real sentences. What's more, they found that when they wrote the method name in the language of the business domain, they generated documents made sense to business users, analysts, and testers.

\begin{shaded}
\center{\glqq Folks who do TDD for a while typically come to the conclusion that the only thing that TDD has to do with testing is the appearance of the word test in its name.\grqq}
\rightline{(Unknown source)}
\end{shaded}

The next rule North introduced was, that test method names should start with the word \textbf{\glqq should\grqq}. Because the class \textbf{should do something}. If you find yourself writing a test whose name doesn't fit this template, it suggests the behavior may belong elsewhere. He recommends to put things which do not fit to the usually behavior of a class in more specific classes. For example, if you have a validation class for information of a person and you come to the validation of age, which can be really complicated regarding legal values, you should write a separated validation class for the age. This validation class can than be added to its owning class via dependency injection.

When a test fails, it is helpful when it has an expressive name. So now you can think about why the test fails. North gives three possible answers:

\begin{itemize}
\item I had introduced a bug. Bad me. Solution: Fix the bug.
\item The intended behavior was still relevant but had moved elsewhere. Solution: Move the test and maybe change it.
\item The behavior was no longer correct -- the premise of the system had changed. Solution: Delete the test.
\end{itemize}

Because North wanted the developers to focus on the behavior of a system and the word \glqq test\grqq\ seems to confuse many developers he later decides to replace the word \glqq test\grqq\ by \glqq behavior\grqq\ when it comes to give the test methods their names. 

North then started his work on JBhave, which is described in Section \ref{SecTools}. His colleague, Chris Matts, helped him to understand the meaning of business value. His next step was to create a consistent vocabulary for analysts, testers, developers, and the business, to eliminate some of the ambiguity and miscommunication that occur when technical people talk to business people.

\subsection{Practices and Process Cycle}
For each unit of the software, the developer must:
\begin{itemize}
\item First define a test-set for this unit
\item Implement the desired behavior
\item Test the implementation with the firstly described test
\end{itemize}

Figure \ref{bddCycleGraphic} shows the BDD-Cycle in a graphical way. It slightly differs from the above description. The graphic says, you start with focusing on one scenario. After that, you write a non-complete or failing step definition. For that step definition, you write a test and refactor it until it shows the behavior described by the failing step definition. If the test is working, you step up and refactor the step definition, until it represents the scenario you are currently focusing on. Now you step inside again and refactor your tests until they validate the behavior of the step definition.
\begin{figure}
\includegraphics[scale=0.5]{images/bddCycle.png} 
\centering
\caption{The BDD Cycle \cite{Force2012}}
\label{bddCycleGraphic}
\end{figure}


To define the desired behavior in a testable way, North and Matts began to describe an ubiquitous language for the analysis process. They started from a well known template, which their company used at this time:
\begin{shaded}
\noindent\texttt{As a [X]\\
I want [Y]\\
so that [Z]}
\end{shaded}

where Y is some feature, Z is the benefit or value of the feature, and X is the person (or role) who will benefit. If there is no easy way to describe Z, this can be an indicator for a low business value. They also discovered that a story's behavior is simply its acceptance criteria - if the system fulfills all the acceptance criteria, it's behaving correctly; if it doesn't, it isn't.

They changed the given template to the following:
%\parbox[b]{\textwidth}{
%\textit{Given} some initial context (the givens),\\
%\textit{When} an event occurs,\\
%\textit{then} ensure some outcomes.}\\\\

\begin{shaded}
\noindent\textit{Given} some initial context (the givens),\\
\textit{When} an event occurs,\\
\textit{then} ensure some outcomes.
\end{shaded}


A complete example is given on North's website \cite{North2012}:
%\parbox[b]{\textwidth}{
%+\textbf{Title}: Customer withdraws cash+\\
%\textit{As a} customer,\\
%\textit{I want} to withdraw cash from an ATM,\\
%\textit{so that} I don't have to wait in line at the bank.}\\\\

\begin{shaded}
\noindent
+\textbf{Title}: Customer withdraws cash+\\
\textit{As a} customer,\\
\textit{I want} to withdraw cash from an ATM,\\
\textit{so that} I don't have to wait in line at the bank.
\end{shaded}


Using the given-when-then template, the first two scenarios might look like this:

\begin{shaded}
\noindent
+\textbf{Scenario 1}: Account is in credit+\\
\textit{Given} the account is in credit\\
\textit{And} the card is valid\\
\textit{And} the dispenser contains cash\\
\textit{When} the customer requests cash\\
\textit{Then} ensure the account is debited\\
\textit{And} ensure cash is dispensed\\
\textit{And} ensure the card is returned
\end{shaded}
%
%\parbox[b]{\textwidth}{
%+\textbf{Scenario 1}: Account is in credit+\\
%\textit{Given} the account is in credit\\
%\textit{And} the card is valid\\
%\textit{And} the dispenser contains cash\\
%\textit{When} the customer requests cash\\
%\textit{Then} ensure the account is debited\\
%\textit{And} ensure cash is dispensed\\
%\textit{And} ensure the card is returned}\\\\
Notice the use of \glqq and\grqq\ to connect multiple givens or multiple outcomes in a natural way.

\begin{shaded}
\noindent
+\textbf{Scenario 2}: Account is overdrawn past the overdraft limit+\\
\textit{Given} the account is overdrawn\\
\textit{And} the card is valid\\
\textit{When} the customer requests cash\\
\textit{Then} ensure a rejection message is displayed\\
\textit{And} ensure cash is not dispensed\\
\textit{And} ensure the card is returned
\end{shaded}
%
%\parbox[b]{\textwidth}{
%+\textbf{Scenario 2}: Account is overdrawn past the overdraft limit+\\
%\textit{Given} the account is overdrawn\\
%\textit{And} the card is valid\\
%\textit{When} the customer requests cash\\
%\textit{Then} ensure a rejection message is displayed\\
%\textit{And} ensure cash is not dispensed\\
%\textit{And} ensure the card is returned}\\

How this acceptance criteria is transformed into code and made testable, will be described in the upcoming sections of this report.
